The technology disclosed relates to the granular analysis of design data used to prepare chip designs for manufacturing and to identify similarities and differences among parts of design data files. In particular, it relates to parsing data and organizing it into canonical forms, digesting the canonical forms, and comparing digests of design data from different sources, such as chip-level designs and design template libraries. Organizing the design data into canonical forms generally reduces the sensitivity of data analysis to variations in the data that have no functional impact on the design. The details of the granular analysis vary among design languages and data file formats used to represent aspects of a design. Depending on the desired analysis and the design languages, granular analysis may include partitioning and reporting design files by header/cell portions, by separate handling of comments, by functionally significant/non-significant data, by whitespace/non-whitespace, and by layer within a unit of design data. The similarities and differences of interest depend on the purpose of the granular analysis. The comparisons are useful in many ways.
The design of an integrated circuit is an iterative process involving hundreds of thousands of cell and block views, artifacts, and their dependencies. The views, artifacts, and their dependencies represent the developing functional, electrical and physical state of an integrated circuit.
Cells and blocks proceed through the design process at different rates, starting with internal cell-level development and release from a design template vendor and cycling through multiple releases or iterations. Keeping track of the most recent version of blocks, libraries, cells, and artifacts is difficult, at best. For example, when someone discovers a yield problem in a product that uses a particular design template, the company will have difficulty determining what other projects use that design template.
The potential for use of an obsolete cell or library is everywhere. Design tools have their own configuration files, and machines have their own search paths and disk mount points. A design or tapeout team may not find an out-of-date file or link until a problematic design comes back from manufacturing.
Complex multi-level designs bring new problems. A frozen block, which was tentatively completed by the design team, might be using an out-of-date version of a library cell. Moreover, a designer might avoid a name conflict with another designer's cell by simply renaming a cell, without verifying whether the two cells are equivalent. Renaming the cell decouples it from future library updates and cell tracking mechanisms.
Designers have made unauthorized modifications to design templates provided by vendors, which resulted in failure during production and potentially voided a warranty otherwise available from the design template vendor. Designers might, for example, think that modifications would improve the performance or functionality of the template, only to find out that they produce the opposite outcome, such as failure in production. Furthermore, third party vendors do not warrant modifications to their design templates. If something does occur like this, it becomes difficult to determine the cause and to identify who is responsible.
When a design is ready for release to production, there can be as many as 40,000 unique cells. With designs as complex as they are today, there is a greater chance that some library cells used to prepare the design are not up to date. The tapeout team cannot determine with certainty whether the cells in the design it is about to send to the mask shop represent the most recent available versions. There is no way today to ensure that a tapeout candidate uses all of the most recent data or ensure that no one made unauthorized modifications to certified layouts.
The known approaches to tracking cell data during the design of an integrated circuit track data files that contain collections of cells. To find cell changes within a file, designers resort to a manual analysis of millions of lines of data typically using a differencing tool. Running a difference check is not effective across design languages or data file formats, because differencing tools typically perform text matches that do not consider the design language or the data type used to represent the design. A differencing program typically subtracts the differences between files, without analysis of whether the changes have a functional impact on the chip being produced or whether they are significant. Differencing tools have a particularly difficult time with two binary data files.
Examples of design tools that apparently include differencing tools include ClearCase, DesignSync and IC Manage, which are described by their respective sellers at http://www-01.ibm.com/software/rational/, http://www.icmanage.com and http://www.3ds.com. Because such tools operate at a file level, rather than a cell level, a designer using a differencing tool would practically need to extract the two sections of code to be compared into new files and compare the files directly. Or, the designer might rely on file metadata, in which another designer has kept notes about the course of design efforts. Neither of these approaches is very robust or efficient.
Some design template suppliers add tags to their templates. The tags identify the templates as theirs with respect to other design templates that may be part of an integrated circuit design that are not their. The tags are used to count the instances of design templates used in a design and then the users of the templates pay royalties based on the number of instances. The standard for the industry approach to the use of this tagging method is maintained by the by the VSI Alliance™. Version 2.0 of the standard, entitled “Virtual Component Identification Physical Tagging Standard,” accessed on May 21, 2009 at http://www.vsi.org/docs/IPP_Tagging_Std%201—30.pdf, describes the way to use the tagging methods. This standard describes text tags to be embedded in GDSII text or comment lines. The VSI Alliance includes IBM, Intel, ARM, Freescale Semiconductor, TSMC and others. Third party IP suppliers have developed a scanner that can detect and report design templates if the tags remain part of the design template data. If the tags are removed or obfuscated in some way, the owners of the design templates will not be compensated in terms of royalties.
An opportunity arises to develop new tools for analysis of design data, which facilitate granular evaluation of design data at various junctures in the design work flow. Better, more error free, more resilient and transparent work flows and resulting product designs may result.